原帖 ｜ Jason ｜ 2026-08-11 14:03 ｜ 👍1 ｜ 阅读约1

今天说一个我常用的嵌入式 Linux 调试小技巧：设备树反编译。

我们修改设备树，只改源码 dts/dtsi，编译烧写，但多文件 include 叠加之后，真正生效的硬件节点，已经是合并之后的结果，原始源码看不出最终真实状态，这就是 dtb 反编译的价值。

• DTS：设备树源码；DTSI：公共头文件，被多个 dts 复用 include

• DTC：设备树编译器，把一堆 dts、dtsi，合并、编译生成二进制 DTB

• DTB 是内核真正加载运行的二进制文件，板子实际生效的配置全部在这里。

多个 dtsi、dts 对同一个节点写属性，编译阶段 DTC 会做属性合并、覆盖。你本地看分散的源码，看不到合并之后真实值，容易踩坑。

dtb 反编译成可读dts文本

dtc -I dtb -O dts xxx.dtb -o out.dts

拿RK3566举例：

find -name *.dtb
dtc -I dtb -O dts rk3566-lubancat-1-mipi1080p.dtb -o dump.dts

打开 dump.dts，这就是板子实际跑的完整设备树，所有 include 合并完毕，没有任何宏，全部是最终生效属性。

什么时候一定要反编译？

1. 同一个硬件节点分散在 rk3566.dtsi、板级 dtsi、板级 dts 多个文件，属性互相覆盖，看源码分不清最终是什么值。反编译dtb 直接看合并之后真实结果。

2. 驱动 probe 失败，怀疑设备树属性写错，直接读 dump 出来的 dts，确认 status、reg、gpio、clock 这些最终值。

3. 拿到别人编译好的 dtb，没有原始 dts 源码，可以反向解析硬件配置（抄板常用，从板子里获取运行时设备树）。

注意事项：

1. 反编译出来的 dts 不能直接拿来编译回dtb，它是 dump 调试版本，丢失 include宏，语法会有小瑕疵（变成 16 进制），只用于阅读排查，不要当做工程源码修改。

2. 不要只看磁盘上的 dts 源码！内核真正认的是 dtb。改完 dts，确认 dtb 是否真的更新，很多时候编译没刷对 dtb，源码改了板子没变化。

3. 像野火鲁班猫这种板子，同一个SOC有很多屏幕变体：hdmi / mipi600p / mipi800p / mipi1080p，对应不同顶层 dts，生成不同dtb，选错 dtb 屏幕直接不工作。排查优先反编译当前实际加载的 dtb。

调试流程建议：

1. 确认板子烧录的是哪一份 dtb

2. 把这份 dtb 拿出来反编译

3. 在 dump 文件搜索报错对应的 node，核对 status、compatible、gpio、interrupt等属性

4. 定位问题之后，再回到原始 dts/dtsi 修改源码，重新编译。

一句话总结：dts/dtsi 是写代码用的，反编译 dtb 才是看板子真实硬件配置的手段。

有的平台支持直接用 adb/ssh 连板子，获取运行时设备树，都可以。

相关笔记

• 📁 返回本主题 MOC
• 从MCU转Linux BSP开发
• Linux BSP问题闭环流程
• 很多人不知道 Android 和 Linux（如 Ubuntu） 的关系
• 嵌入式 Linux 橙皮书系列更新 v2.0.0 版本
• Linux驱动工程师工作日常
• 嵌入式Linux调试iic